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La presente invention conceme un systeme de consultation et /ou mise a jour de 
serveiirs DNS (Domain Name System) et/ou d'annuaires LDAP (Lightweight 
Directory Access Protocol) k partir d'un terminal. La presente invention permet 
notamment a un abonne, a partir d'un terminal quelconque, de consulter et de mettre 
a jour un enregistrement de ressources de telecommunication stocke dans un serveur 
DNS ou LDAP. 

Les serveurs DNS (et LDAP) sont utilises dans le monde informatique pour 
nommer des machines (par exemple: association d'une URL web a une adresse IP 
correspondant au serveur web hebergeant ce site web). Ces serveurs sont 
habitueliement consult6s par des machines informatiques au moyen d'xm logiciel 
communement appele RESOLVER, disponible dans la plupart des terminaux ou 
serveurs informatiques. Ce logiciel permet d'extraire une information d'un serveur 
DNS en r^ponse a la requete d'un client. Cette information peut etre disponible 
directement aupres du premier serveur DNS consulte ou bien aupres d'un serveur 
DNS reference par le premier, et ainsi de suite si necessaire par iadirectio'ns 
successives. Les contenus des serveurs DNS sont mis a jour par des specialistes 
"administrateur" et de manidre peu frequente (mise a jour de fichiers a plat sous 
plateforme UNIX ou application d^di^e via IHM sous les plate-formes serveurs 
Windows). Le format des contenus des serveurs et des requStes sont ddfinis dans^un 
protocole, dit protocole DNS decrit dans les documents RFC 1034 et RFC 1^0^5, 
disponibles sur le site web de I'lETF (www.ietf.org). 

D'autre part, les serveurs DNS sont desormais appeles a jouer un r61e dans le 
cadre du service ENUM visant k oflfrir aux abonnes une portabilite generalis^e de 
num6ro de telephone. Ce service ENUM utilise le systfeme de numerotation 
telephonique international defini par TUIT sous la recommandation E.164. Plus 
precisement, le service ENUM permet a tout abonne disposant d'une numero 
telephonique unique E.164 (numero de telephone de type +33296053859) d'etre joint 
par diflFerents moyens en fonction de . ses preferences configurees dans un profil 
heberge dans le reseau par un serveur DNS. Par exemple, le numero de telephone 
unique E.164 de Fabonne ENUM peut etre associe a un numero de telephone mobile 
(+33686166924), a un numero de telephone fixe (-1-33296916404), a une adresse 
eMail (bertrand . dupont (a)rd. franceteleconv con) ), a une URL de site web 
( http://vvv\av.bertrand.dupont.com ), a un numero de telephone VoIP 
(sip:bertrand.dupont@sip.francetelecom.com), k un numero de fax, etc. 
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L'ensemble de ces informations peuvent etre stockees dans un serveur DNS 
standard et accedees selon le module de delegation hierarchique represente en Fig. 1 . 

L'acces se fait par un serveur DNS racine (E164.ARPA). Chaque pays dispose 
ensuite d'un code teiephonique unique (33 pour la France) et un serveur DNS est gere 
au niveau 1 par chaque pays (3.3.E164.ARPA pour la France). Des operateurs de 
telecommunications ou des foumisseurs de services ENUM gerent enfin des serveurs 
DNS (indique en Fig. 1 par DNS 1 h DNS 6) en fonction des ressources telephoniques 
(tranche de numeros telephoniques E.164) qui leur sont attribuees. Le modele retenu 
est un d^coupage par tranches: 5 tranches de numeros de telephone fixes RTC avec 
des prefixes allant de 1 a 5 et une tranche de numeros de telephone mobile identifiee 
par le pr^fixe 6. 

A un numero de telephone au format E.164, est associe un chemin dans 
I'arborescence des serveurs DNS. Phis precisement, chaque numero de telephone au 
format international E.164 est inverse, le code "+" est supprime, un point est ajoute 
entre chaque chififre et le resultat obtenu est accole au domaine el64.arpa de maniere a 
transformer le numero de telephone en un nom de domaine Internet unique. Par 
exemple, le numero de telephone +33686166924 donne apres transformation, le nom 
de domaine Internet 4.2.9.6.6.1.6.8.6.3.3.el64.arpa. 

D'autre part, a chaque numero de telephone au format E.164 est associe un 
enregistrement comprenant un ou des enregistrements de ressources (Resource Record 
ou RR), stockes dans le serveur de niveau 2 correspondant, chaque enregistrement de 
ressource pouvant comprendre un ou plusieurs champs. Par exemple, a un numero de 
telephone au format E.164 peuvent etre associes des enregistrements de ressource 
NAPTR (Naming Authority PoinTeR), tels que definis dans les documents RFC 2915 
et RFC 2916, disponibles sur le site de I'lETF. De maniere schematique, un 
enregistrement de ressource NAPTR indique un service de telecommunication (n* de 
tel, fax, adresse eMail, site web etc.) associe a un niveau de priorite. On appellera par 
la suite enregistrement ENUM (ou profil ENUM) un ensemble d'enregistrements 
NAPTR associes a un nom de domaine Internet. Par exemple, si le profil ENUM 
suivant est stocke dans un serveur DNS de niveau 2 : 



SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64 .arpa. 

IN NAPTR 100 10 "u" "tel+E2U" "!^*$!tel:+33296053859!" 
INNAPTRlOOll V "tel+E2U" "!^*$!tel:+33296916404!" 
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INNAPTR 100 12 "u" "tel+E2U" "!^*$!tel:+336861 66924! 

INNAPTR 100 13 "u" "sip+E2U" "!^*$!sip:bdupont@sip.ftrd.fr!" 

INNAPTR120 10 "u" "maato+E2U" "!^*$!InaiJ2:bdupon^@^d.ftrd.fr!" . 

IN NAPTR 130 10 "u" "http+E2U" "!^*$!http://Avww.bdupont.fr!" 

La ligne d'en-tete indique un nom de domaine Internet correspondant au numero 
de telephone E.164. Le logiciel RESOLVER permet a partir du nom de domaine 
d'acceder a Tenregistrement. A chaque enregistrement NAPTR de I'exemple ci- 
dessus correspond une ressource ou service de telecommunication. Deux champs 
numeriques suivent le terme « NAPTR », il s'agit respectivement des priorites de 
service: "Ordre" et "Preference". Plus la valeur du champ "Ordre" est faible, plus le 
service est prioritaire et si plusieurs services ont un niveau d'ordre identique, plus la 
valeur de PreSrence associee est faible, plus le service est prioritaire. Ainsi, les Ugiies 
de I'enregistrement ci-dessus correspondent a des priorites decroissantes. "f^ 
La ligne correspond au service telephonique fixe 0296053859 avecl^in 
ordre= 1 00 et une preference =10. ' 

La 2^^ ligne correspond au service telephonique fixe 0296916404 avec*"tm 
ordre=100 et une preference=l 1 . - 
La 3^"^ ligne correspond au service t6I6phonique mobile 0686166924 avec 'tin 
ordre=100 et imepr6ference=12 . * , ytf 

La 4^"^ ligne correspond au service telephonique IP via SIP vers Tadresse SIP 
bdupont@.sip.ftrd.fr avec un ordre=100 et une preference=13 , 

La 5^ ligne correspond au service de courrier electronique eMail dont Fadresse 
de destination est bdupont@rd.ftrd.fi: avec un ordre=120 et une preference=10 . 

Enfin, la 6^ ligne correspond au service web dont FURL d'accds est 
http://v\nvw.bd upont.fr avec un ordre=130 et une preference=10 . 

La signification de cet enregistrement est la suivante. Si Ton cherche a joindre le 
numero de telephone E.164 (+33296053859), le logiciel RESOLVER transmet une 
requete au serveur DNS niveau 2 avec le nom de domaine Internet correspondant 
(9.5. 8.3.5.0.6.9.2.3.3. el64.arpa). En retour, le serveur DNS niveau 2 (DNS2) fourhira 
dans la r6ponse la liste des ressources de telecommunication (egalement denommes 
ci-apres services) associes au numero de telephone +33296053859, telle que donne 
par renregistrement. Le logiciel RESOLVER et le service ENUM pourront alors 
exploiter tout ou partie de ces ressources en mode sequentiel (le systeme tentera de 
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joindre le service le plus prioritaire puis, en Tabsence de reponse ou en cas 
d'occupation, le systeme essaiera de joindre le service de moindre priorite, etc.) ou en 
mode difiusion (le service ENUM tentera alors de joindre simultanement Tensemble 
des services). 

5 La modification des profils ENUM dans un serveur DNS s'accommode mal du 

precede de mise a jour par administrateur tel que connu de Tetat de la technique* En 
eflfet, au contraire des noms de domaines Internet, les services classiques de 
telecommunication tels que le t616phone ou la telecopie sont susceptibles de 
modification fi-equente. Qui plus est, il est quelquefois necessaire de programmer ces 

10 modifications de maniere automatique sur ime base quotidienne voire horaire. II est 
alors extrSmement difficile pour des raisons de disponibilite et de flexibility de faire 
supporter la modification de configuration d'un profil ENUM a son propre operateur 
de telecommunications ou a son foumisseur de service ENUM, 

Un probleme particulier a la base de 1' invention est de permettre a un abonne 

15 une consultation et/ou une modification simple et rapide de son profil ENUM stocke • 
dans un serveur DNS ou un annuaire LDAP. 

De maniere plus generale, le probleme a la base de Tinvention est de permettre 
une consultation et/ou modification simple et rapide d'un ou de plusieurs 
enregistrement(s) de ressource stocke(s) dans un serveur DNS ou LDAP et ce, a partir 

20 d'lm terminal conventionnel quelconque, 

Le probleme a la base de Tinvention est resolu par un systeme de consultation 
et/ou de mise a jour d'un enregistrement stocke dans une premiere base de donnees, 
ledit enregistrement comprenant un ou une pluralite d'enregistrements de ressources, 
ladite premiere base de donnees etant hebergee par un serveur de noms de domaine, 

25 dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant etre accede par 
indirection a partir d'un serveur DNS, ledit systeme comprenant: 

- des moyens de communication permettant audit systeme de recevoir d'un 
terminal de telecommum'cation une demande de consultation et/ou de modification 
dudit enregistrement ou une programmation d'une telle demande ; 

30 - des moyens de controle adaptes a determiner a partir de ladite demande de 

consultation et/ou de modification transmise au dit systeme ou prealablement 
programmee dans ledit systeme, un nom de domaine et une operation a effectuer sur 
ledit enregistrement ; 
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- des moyens de gestion de protocole adaptes a rechercher a partir dudit nom de 
domaine, Tadresse IP dudit serveur hebergeant ladite premiere base de donn6es et, en 
fonction de ladite operation, k transmettre au dit serveur une requete de lecture ou de 
mise a jour dudit enregistrement. 
5 Avantageusement, ledit systeme cqmprend des moyens d'authentification 

adaptes a authentifier au niveau applicatif F^metteur de ladite demande a partir 
d'informations d'authentification stockees dans une seconde base de donn^es locale 
ou distante. 

Lorsque Temetteur de ladite demande a ete authentifie, lesdits moyens de 
10 gestion de protocole permettent de transmettre une requete en consultation selon le 
protocole DNS (DNS Query) audit serveur DNS, la requete ayant pour argument ledit 
nom de domaine, et a recevoir une premiere reponse dudit serveur. 

Selon un mode de realisation, les moyens de controle sont adaptes a determiner 
ledit nom de domaine a partir d'un identiJBant d'abonne qui pourra etre le nrnnero 
15 telephonique E, 164 dudit abonne. 

Les moyens de controle sont alors adaptes a extraire des informations et a 
determiner en fonction de ladite demande ime operation a eflfectuer sur^om 
enregistrement de ressource de type NAPTR. 

Selon d'autres modes de realisation les moyens de controle sont adapt&^^a 
20 extraire des informations et a determiner en fonction de ladite demande une operation 
a effectuer sur un ou plusieurs enregistrements de ressource de type A, NS, MD, MF, 
CNAME, SOA, MB, MG, Nm, NULL, WKS, PTR, HI^ 

Les caracteristiques de I'invention mentionn^es ci-dessus, ainsi que d'autres, 
25 apparaitront plus clairement a la lecture de la description suivante d'un exemple de 
realisation, ladite description etant faite en relation avec les dessins joints, parmi 
. lesquels : . 

la Fig. 1 iUustre schematiquement le modele de delegation utilise dans le service 
ENUM; < \ . . . . ■ . 

30 la Fig. 2A illustre schematiquement un exemple d'environnement du systeme 

selon r invention; 

la Fig, 2B . illustre schematiquement Tenvironnement de la Fig. 2A dans le 
contexte du service ENUM ; 
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la Fig. 3 A represente le schema de principe du systeme de consultation/ mise a 
jour selon T invention ; 

la Fig. 3B represente un exemple de systeme de consultation/ mise a jour selon 
rinvention ; 

5 la Fig. 4 represente schematiquement une procedure de consultation et mise a 

jour manuelle d'un profil ENUM avec acces en mode vocal ; 

la Fig, 5 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM par envoi de messages SMS ; 

la Fig. 6 represente schematiquement une procedure de consultation et mise a 
1 0 jour manuelle d'un profil ENUM par le Web ; 

la Fig. 7 represente schematiquement une procedure de consultation et mise k 
jour manuelle d'un profil ENUM a partir d'un Minitel; 

la Fig. 8 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM par eMail; 
15 la Fig. 9 represente schematiquement une procedure de consultation et mise k 

jour manuelle d'un profil ENUM par lUU a partir d'un terminal RNIS; 

la Fig. 10 represente schematiquement une procedure de programmation de mise 
automatique de profil ENUM ; 

la Fig. 11 represente schematiquement une procedure de mise a jour 
20 automatique de profil ENUM; 

la Fig. 12 represente schematiquement une procedure de consultation de profil 
ENUM lorsque ce dernier est stocke dans un annuaire LDAP ; 

la Fig. 13 represente schematiquement une procedure de mise k jour de profil 
ENUM lorsque ce dernier est stocke dans un annuaire LDAP, 

25 

La Figure 2A illustre un exemple d'environnement du systeme selon I'invention. 

Des foumisseurs de service de gestion de ressources de telecommunication, ci- 
apres denommes foumisseurs de service, ont ete schematiquement representes en 
30i,...,30n. Chaque foumisseur de service dispose d'un serveur DNS (31i) ou LDAP 
30 (34{) hebergeant une base de donnees et plus generalement de plusieurs serveurs 
redondants de maniere a augmenter la fiabilite de I'acces au service. La base de 
donnees contient un enregistrement des ressources de telecommunication pour tous les 
abonnes du foumisseur de service en question. 
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Le systeme (50) selon rinvention peut etre connecte d'une part au reseau 
telephonique public via une interfece standard de type analogique ou numerique TO ou 
T2 et, d'autre part, au reseau IP via une interfece standard de type Ethernet. 

Plus precisement, le systeme (50) est connecte au r6seau Internet si la pr6sente 
5 invention est accessible a tout abonn^, quel que soit son foumisseur de service, et 
pourra etre connecte ^ un r6seau Intranet si la presente invention est accessible aux 
seuls abonnes d'un foumisseur de service, 

Le systeme (50) pourra etre accede par un terminal telephonique RNIS (2) 
connecte soit directement soit a travers un PABX (3) au reseau RNIS (10). On 
10 rappelle que le reseau RNIS est interconnecte nativement au reseau RTC. 

Le systeme (50) pourra aussi etre accede par un terminal telephonique classique 
(4) ou un terminal Minitel (5) connect^ au reseau RTC (11). 

Le systeme (50) pourra encore etre accede par un terminal mobile GSM (6) ou 
encore \m terminal UMTS non represente (les reseaux GSM- et UTRAN^^sont 
15 interconnect^s nativement au rdseau RTC). 

Le systeme (50) pourra etre accede au moyen d'lm terminal telephonique IP (7) 
connecte au reseau IP (13). 

Le systdme (50) pourra enfin etre acc^d^ au moyen d'un micro-ordinateur (8) 
relid au reseau IP soit au travers une interfece Ethernet (reseau local d'entreprise^soit 
20 par modem (RTC/RNIS/ADSL/cable/satellite etc.) 

L'abonne pourra en outre recevoir des notifications du systeme (50) grace a Fun 
des terminaux envisages ci-dessus ou bien encore a I'aide d'un terminal fex (9). 



La Figure 2B illustre un exemple d'environnement du systeme selon Pinvention, 
25 dans le contexte d'un service ENUM. Les Elements portant les memes num^ros de 
reference sont identiques a ceux de la Fig. 2A. . 

On a indique en 40 le serveur DNS ENUM de niveau 0 (racine). Ce serveur 
dispose de Tensemble des adresses IP reftren9ant Fensemble des serveurs DNS 
ENUM de niveau 1, correspondant aux codes des different s pays (33 pour la France, 
30 34 pour J'Espagne, 44 pour TAngleterre, etc.). Par exemple, on a feit figurer en 41 le 
serveur DNS ENUM de niveau 1 correspondant a ia France. 

Chaque operateur ou foumisseur de service ENUM dispose d'au moins un 
premier serveur DNS ENUM de niveau 2 (3li), dit serveur primaire, redonde par au 
moins un second serveur DNS ENUM de niveau 2 (Sl'i), dit serveur secondaire, ce 
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afin d'assurer une bonne fiabilite de service. Le serveur primaire (resp. secondaire) 
heberge une base de domiees 33, (resp. 33 'i). Dans chaque serveur de niveau 2, est 
stocke, pour chaque numero de telephone E.164 d'abonne au service ENUM, un profil 
compose des diflferentes ressources de telecommunication de Fabonne, chaque 
ressource correspondant a un moyen d'acces (par ex, telephone fixe bureau, telephone 
fixe domicile, telephone mobile, telephone IP, adresse eMail du bureau, adresse eMail 
du mobile, N'' de fax professionnel, etc.) ainsi que les priorites aflferentes a chacun de 
ces moyens d'acces. Chaque ressource de telecommunication est declaree au moyen 
d'un enregistrement de ressource NAPTR comme on I'a vu plus haut. La priorite 
d'une ressource est determinee par le contenu des champs Ordre et Preference de 
Tenregistrement de ressource NAPTR, tels que definis dans le document RFC 2915 de 
riETF et exemplifies dans la partie introductive. 

Un foumisseur A de service ENUM (30i) peut egalement disposer d'un serveur 
LDAP (34i) hebergeant un annuaire dynamique LDAP (36i) tel que defini dans le 
document RFC 1959 de FIETF. L'interet de cette configuration est de permettre de 
gerer les profils ENUM par indirection non plus dans le DNS ENUM niveau 2 mais 
dans i'annuaire dynamique LDAP. L'avantage procure consiste a ne plus modifier le 
profil du client ENUM au niveau du serveur DNS ENUM niveau 2 mais directement 
dans Tannuaire LDAP qui, lui, est con9u pour stocker des profils dynamiques. Dans ce 
cas, le DNS ENUM niveau 2 (310 contient par exemple le profil suivant pour 
Tensemble des num^ros de telephone E.164 commen^ant par le prefixe "+332": 

SORIGIN 23,3.el64.arpa, 
IN NAPTR 100 10 "u" "ldap+E2U" 
"!^+332(.*)$!ldap://Idap.foumisseurA.fr/cn-01 ^ 

L'annuaire LDAP (36i) est accede par indirection a partir du serveur DNS 
ENUM de niveau 2 et contient les enregistrements de ressource pour les differents 
abonnes du foumisseur A. 

Un serveur ou une passerelle ENUM (80) peut consulter un foumisseur de 
service ENUM (30,) pour connaitre la liste des ressources de telecommunication d'un 
abonne ENUM. Pour ce faire, le logiciei RESOLVER transforme le numero unique 
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E.164 de I'abonne en nom de domaine comme on Va vu plus haut et accede par 
indirections successives an serveur DNS ENUM niveau 2 (31,) et, le cas 6cheant, 
apres indirection supplementaire au serveur LDAP (34i). Le foumisseur de service 
retoume la liste des ressources de Tabonne en question avec les priorites associees. Le 
serveur ou la passerelle ENUM (80) peut alors, selon le cas, tenter de joindre Tabonne 
en utilisant successivement les ressources, par ordre decroissant de priorite ou joindre 
Tabonne au moyen de Tensemble de ses ressources. 

La Fig. 3A represente le schema de principe du systeme (50) de mise a jour 
selon rinvention . . ^ . i : 

Le systeme comprend des moyens de communication (1150) permettant a un 
aboxme de dialoguer avec ledit systeme et notamment : 

de transmettre a rabonne une requete en authentification ; ^g^. 
de recevoir dudit abonne des informations permettant (>son 
authentification; - , . . . . 

- de recevoir dudit abonne une demande de . modification dJun 
enregistrement (dite demande manuelle) ou une demande ^de 
modification automatique (dite demande programmee) en fonction d|un 
.critere temporel ou geographique ; - -t^- 
de transmettre. le , contenu d'un enregistrement prealablement ou 
posterieurement a la demande de modification ; . . 

de transmettre au dit abonn^ une notification de confirmation de mise a 
jour lorsque la modification demandee a bien ete effectuee et 
d'infirmation de mise a jour lorsque cette demiere n*a pu etre effectuee; 
de transmettre au dit abonne, a. fin de consultation ou revision, une 
demande de modification automatique prealablement enregistree dans 
ledit systeme ; , . . ' . 

de transmettre au dit abonne un historique des modifications effectuees. 

Le systeme comprend egalement des moyens d'interface (1160) permettant de 
connecter lesdits moyens de communication au r^seau RTC/RNIS.et/ou a un reseau IP 
(Internet ou Intranet). . . r . , . , , 
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Le systeme comprend encore des moyens d'authentification (1173) cooperant 
avec les moyens de communication pour authentifier au niveau applicatif un emetteur 
de demande de consultation et/ou mise k jour. L'authentification au niveau applicatif 
presente I'avantage de permettre a un abonn6 d'operer a partir de n^importe quel 
5 terminal. Les moyens d'authentification utilisent pour ce faire des informations 
d'authentification stockees dans une base de donnees (11 70) locale ou distante • 

Outre les informations susmentionnees, la base de donnees (1170) pent 
notamment contenir des programmes de modification automatique relatifs a differents 
10 abonnes, les adresses IP des serveurs des diflKrents foumisseurs de gestion de 
ressources de telecommunication, les historiques de modifications manuelles ou 
automatiques des enregistrements, les adresses auxquelles les notifications de 
confirmation/infirmation de mise a jour doivent etre transmises. 

15 Le systeme (50) comprend encore des moyens de gestion de protocole (1162) 

assurant entres autres la fonction RESOLVER. En particulier les moyens de gestion 
de protocole sont adaptes a rechercher, le cas echeant par indirections successives, le 
contenu d-un enregistrement de ressource (RR) a Faide d'un nom de domaine. Les 
moyens de gestion de protocole peuvent transmettre a cette fin des requetes de 

20 consultation selon le protocole DNS (DNS Query). En outre, les moyens de gestion 
de protocole peuvent mettre a jour des enregistrements de ressources a partir de 
requetes de mise a jour (DNS Update). Selon un mode de realisation, si des 
enregistrements de ressources sont stockees dans un annuaire LDAP, les moyens de 
gestion de protocole permettront egaiement la consultation d'un enregistrement dans 

25 un annuaire LDAP (emission d'une requete LDAP Search) ainsi que la mise a jour de 
cet enregistrement (emission d*une requete LDAP ModiJ[>0- Lorsque la mise a joiu* a 
ete realisee, les moyens de protocole regoivent un acquittement du serveur du 
foumisseur de gestion de ressources de telecommunication. 

30 Les moyens de controle 1 175 coordonnent les moyens precites et notamment : 

ordonnent aux moyens de communication la transmission d'une requete 
en authentification ; 
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apres authentification de Pabonne par les moyens d'authentiiication 
(1173) demandent aux moyens de protocole (1162) de transmettre une 
requite en consultation, formatent la reponse et la retransmettent sous 
forme intelligible a Tabonne via les moyens de communication; 
a partir d'une demande en modification d'un enregistrement de ressource 
par un abonne, determinent une operation a effectuer sur ledit 
enregistrement et un identifant de Tabonne 

sur reception de conjSrmation/iniSrmation de mise k jour par les moyens 
de protocole, notifient la confirmation/infirmation a Tabonne via les 
moyens de commimication. 

La Fig. 3B illustre un exemple de realisation de Tinvention dans le contexte 
d'un service ENUM. : 

Les elements portant les memes numeros de reference sont identiques a ceux de 
la Fig. 2A. En particulier, Tabonn^ pourra contacter le systeme de mise a jour (-50) au 
moyen de Tun des terminaux envisages plus haut. En (30) a ete represent^ un 
foumisseur de service de gestion de ressources de telecommunication comprenant un 
serveur DNS de niveau 2 (31), dit serveur primaire, redonde par un serveur secondaire 
(non represente). Le serveur (31) comporte une base de donnees (33) et une pile de 
protocole DNS (32) integrant les protocoles DNS decrits dans les documents^^RFC 
1034 et RFC 1035. La pile de protocole integre egalement les protocoles DNS decrits 
dans les documents RFC 2136 et RFC 2137 destines a permettre la mise a jour (DNS 
Update) d'un enregistrement de ressource (RR). De manidre optionelle, le foumisseur 
de service de gestion de ressources comprend aussi un serveur d'annuaire LDAP (34) 
hebergeant une base de donnees (36). Le serveur d'annuaire LDAP comporte une pile 
de protocole LDAP (35). 

Les moyens de communication du systeme (50) sont constitues des modules 
suivants : 

o un module ayant en charge le traitement des appels telephoniques 
entrants et sortants (52). Ce module gere I'etablissement et la liberation 
de la communication ; 

o un module (53) de gestion d' Information d'Usager a Usager (lUU) 
permettant d'extraire et de transmettre des informations lUU ; 
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o un module (54) de traitement des codes DTMF, Ce module a en charge 

la recuperation des DTMF saisis par Tabonne ; 
o un module (55) de synthese vocale ; 

o un module (56) de difRision de fichiers vocaux pre-enregistres et 

concatenes pour former des phrases ; 
o un serveur videotex (57) ; 
o un module de reception et d'envoi de SMS (58) ; 
o un module d'envoi de fax (59) ; 

o un serveur SMTP (61) permettant Femi^ion et la reception d'eMafl ; 
o un serveur Web dynamique (63). 

II convient de noter que le systeme peut comprendre egalement un module de 
reconnaissance vocale (non represente) adapte a reconnaitre une information 
prononcee par I'abonne. 

Les moyens de communication sont relies a Texterieur au moyen d'une interface 
RTC et/ou RNIS (51) et une interface IP (60). La premiere est basee soit sur une carte 
analogique RTC multi-port soit sur une carte RNIS TO (2 canaux) ou T2 (30 canaux). 
La seconde est une interface Ethemet. La passerelle indiquee par (14) rappelle que les 
reseaux RTC/RNIS et IP sont nativement interconnectes en protocole VOIP 
(H323/SIP). 

Le systeme (50) comporte, comme precedemment, des moyens 
d'authentification (73) autorisant rauthentification applicative des abonnes du service 
a partir d' informations d'authentification, par exemple des couples de pseudonymes 
(Login id) et de mots de passe stockes dans une base de donnees (70) locale ou 
distante. En outre, la base de donnees comprend les identifiants des differents 
foumisseurs de service ENUM (tel que 30), les adresses IP ou les noms de machine 
des DNS tiers 2, des demandes de modification automatique de profil ENUM, les 
historiques de modification manuelle ou automatique de profils ENUM, les adresses 
de notification de modification du profil ENUM (N° de fax, SMS, eMail). 
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Le systeme comprend encore un module de gestion de protocole DNS (62), de 
preference dans sa forme securisee (DNSSec). Ce module joue en particulier le role de 
RESOLVER pour la lecture des enregistrements de ressource. 

Le cas echeant, vm module de gestion de protocole LDAP (64) y est adjoint pour 
5 permettre la lecture et la modification d'enregistrements dans un aimuaire LDAP. 

Le systeme comprend egalement un module (72) permettant la configuration des 
adresses des serveurs DNS de niveau 2 ainsi qu'un module (71) charge de tenir a jour 
les modifications manuelles ou automatiques des profils ENUM et d'elaborer, le cas 
10 echeant, des statistiques pour Texploitant du systeme. 

Les moyens de controle sont constitues, d'une part, d'un module (74) charge de 
la configuration automatique de profils ENUM a partir de demandes de modification 
automatique programmees par des abonnes et stockees dans la base de donnees*:(70) 
15 et, d'autre part, d'un module (75) charge de la configuration « manuelle » des profils 
ENUM. Ce dernier gere des scripts ENUM, notamment un script de lecture de profil 
ENUM (on rappelle qu'un profil ENUM est constitue d'une liste d'enregistrements de 
ressource NAPTR), des scripts de modification des champs des enregistrementis; de 
ressource NAPTR et notamment des champs ordre, preference, service (adresse eMail, 
. . 20 numero de telephone, adresse , eMail etc.). Si Ton souhaite pr^voir la consultation 
et/ou la mise a Jour d'enregistrements de ressource DNS autres que NAPTR, des 
scripts supplementaires doivent etre prevus pour leur modification. - 

La Fig. 4 illustre schematiquement une procedure de consultation et de 
25* modification manuelle d'un profil ENUM en mode vocal via un telephone fixe ou 
mobile de type RTC, RNIS, GSM ou IP. 

L'abonn6 ENUM emet a I'etape 100 un appel telephonique gratuit (type numero 
vert) ou payant selon un mode de remuneration geographique ou forfaitaire de type 
audiotel ou numeros coloies depuis un terminal fixe RTC (4) ou RNIS (2) connecte 
30 sur le reseau public ou derriere un PABX (3) ou un terminal mobile (6) de type GSM, 
ou depuis *un terminal IP (7) a destination de I'tnterface RTC/RNIS (51) du systeme 
(50). L'automate de traitement d'appel (52) accepte automatiquement Tappel entrant a 
I'etape 101. Le module script ENUM (75) donne a Petape 102 Tordre au module de 
s>Tithese vocale (55) ou au module de difiiision de fichiers vocaux (56) de diJBxiser a 
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Tetape 103 vers Tabonne ENUM une annonce vocale invitant Tabonne ENUM a saisir 
son numero ENUM E.164 ainsi que son pseudonyme et son mot de passe . L'abonne 
ENUM saisit a Tetape 104 via son clavier ces informations qui sont vehiculees dans la 
bande sous forme de DTMF et qui sont interceptees par le module de traitement des 
5 DTMF (54). Ces informations sont foumies a Tetape 105 au module d'authentification 
(73) qui interroge la base de dorai^es locale ou distante (via par exemple une interface 
de type ODBC (pour Open DataBase Connectivity)) en operant une recherche sur le . 
Numero ENUM E.164. Celle-ci foumit a Tetape 107 les informations 
d'authentification correspondantes au module d'authentification (73). Ce dernier 

10 compare le pseudonyme et le mot de passe saisis par le client ENUM avec les 
informations d'authentification contenues dans la base de donnees (70). En cas de 
concordance, le module d'authentification (73) ordonne a Tetape 108 au module de 
synthese vocale (55) ou au module de difiRision de fichiers vocaux de difiiiser a 
Tetape 109 vers Tabonne ENUM une annonce du type "Pour consulter votre profil 

15 ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 2, 
pour configurer de maniere automatique votre profil tapez sur 3, pour modifier votre 
pseudonyme-mot de passe tapez sur 4, pour acceder a votre journal de modification de 
votre profil tapez 5, etc. Si Tabonne ENUM tape sur la touche 1 de son clavier 
telephonique a Tetape 110, le code DTMF correpondant est intercepts par le module 

20 de traitement des DTMF (54) et est retransmis a Tetape 1 1 1 vers le module script 
ENUM (75). Le script ENUM (75) detecte alors qu'il s'agit d'lme commande de 
lecture du profil ENUM. Le script ENUM (75) 6met alors a I'etape 1 12 une demande 
d'interrogation au module protocole DNS (62) en foumissant en argument I'adresse 
E.164 de Tabonne ENUM mise sous forme de domaine (transformation du numero de 

25 telephone E.164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module 
de gestion de protocole DNS (62) qui joue le role classique d'un RESOLVER peut 
d'abord verifier si les informations ne sont pas presentes dans son cache suite a une 
consultation precedente ou interroger (a Tetape 113) selon le protocole standard DNS 
(requete DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS 

30 de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). Pour 
gagner en efficacite, les donnees d'un enregistrement NAPTR sont chargees dans la 
memo ire vive du serveur DNS (31). Si rabonne ENUM est eSectivement enregistre 
dans le serveur DNS (31) du foumisseur de service ENUM (30) alors la pile de 
protocole DNS (32) retoume (a I'etape 114) au module protocole DNS (62) la liste 
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des enregistrements NAPTR correspondants. Le module de protocole DNS (62) se 
charge ensuite de les retransmettre vers le module Script ENUM (75) k Tetape 115. Le 
module (75) analyse et interprete les enregistrements NAPTR et genere un texte 
comprehensible par Fabonne ENUM du type "Service N® 1: telephone vers le 
5 0296053859, service N^2: telephone vers.le 0686166924, service N^'S: eMail vers 
bertrand, dupont(Sird. francetelecom . com, etc). Ce texte est envoye vers le module de 
synthese vocale (55) a Tetape 116 qui se charge de diflftiser cette information a 
Tabonne ENUM a Fetape 117. Dans le cas ou le module de diSusion de fichiers 
vocaux (56) est utilise, le module (75) genere Tenchainement des fichiers vocaux a 
10 jouer. 

Apres diSusion de cette information, le module de synthese vocale (55) ou le 
module de diffusion de fichiers vocaux (56) drfiiise a nouveau a Tetape 118 la liste 
des operations d'administration possibles sur le profil ENUM "Pour consulter ^yotre 

• profil ENUM taper sur la touche 1, poxir modifier les attributs de votre profil taper sur 
15 2^ pour configurer de maniere automatique votre profil tapez sur 3, pour modifier 

. votre pseudonyme-mot de passe, tapez sur ,4, pour acceder. a votre journal de 

• modification de votre profil tapez sur 5, etc.). ^ ^ . - ^ 

Si Tabonne ENUM choisit la modification de son profil ENUM a retape^d50, 
. cette commande est interceptee par le module script ENUM (75) a I'etape 151, suite a 
20 la detection du code DTMF par le module de traitement DTMF (54). Le syst6m!^i(50) 
entre alors dans, im dialogue iteratif base sur la diSusion de messages vocaux vers 
I'abonne ENUM a partir d'un texte genere par le module script ENUM (75) (a I'etape 
.152) en fonction du contexte et diffuses (a Tetape 153) sous forme .vocale par le 
module de synthese vocale (55) ou par le module de diSusion de fichiers vocaux 
25 • concatenes (56). Ce dernier vaUde les chobc proposes en utUisant son clavier DTMF a 
• Tetape 154 et les commandes sont transmises a I'etape 155 vers le script ENUM (75). 
Par exemple, le. dialogue vocal pent etre .le suiyant: 

o pour modifier I'ordre/preference de vos services tapez sur 1, pour modifier 
3Q : ' . les attributs d'un service tapez 2, pour ajouter un service tapez 3, pour 
supprimer un service tapez 4,etc. • . 

o ->4 
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o pour supprimer le numero de telephone 0296053859 tapez 1, poxir 
supprimer le numero de telephone 0686166924 tapez 2, pour supprimer 
I'adresse eMail bertrand.dupont@rd,franceteleconi.com tapez 3, etc. 

o ^2 

o Pour valider voire choix tapez 1 , sinon tapez 2 
o ->1 

o Pour supprimer un service tapez 1, poxir enregistrer vos modifications tapez 

2, pour revenir au menu principal tapez sur 0 
o ->2 

Lorsque Fabonne ENUM demande la prise en compte des modifications du 
profi] ENUM, le module script ENUM (75) emet une requete de demande de 
modification a Tetape 156 vers le module protocole DNS (62). Ce dernier emet une 
commande DNS UPDATE a I'etape 157 a destination du module protocole DNS (32) 
du serveur DNS (31) du foumisseur de service ENUM (30), II est rappele que 
I'adresse IP de ce dernier est stockee dans la base de donnees (70) et qu*eUe est 
retrouvee a partir du numero E.164 de Fabonne ENUM. Le module protocole DNS 
(32) met a jour rinformation dans la memoire vive du serveur (31) et demande la mise 
a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 
protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
le/les DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette modification k 
des intervaUes de temps predefinis. La base de donnees (33) confirme la mise a jour a 
Petape 159, ce qui se traduit par une reponse a la requdte de demande de Petape 160. 
Le script ENUM (75) intercepte a Tetape 161 le code retour de cette reponse puis 
genere a Petape 162 le message de confirmation/infirmation de prise en compte de la 
modification. Le module de synthese vocale (55) ou le module de diffusion de fichiers 
vocaux diffuse cette information vers Tabonne ENUM a Petape 163. Ce dernier pent 
alors liberer la communication, 

Selon une variante de cette procedure, en reponse aux messages vocaux, 
Pabonne peut foumir directement une reponse de maniere vocale. C'est alors le 
module de reconnaissance vocale qui determine le choix ou rinformation contenue 
dans la reponse. 
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La Fig. 5 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM via Tenvoi de SMS depuis des teiminaux 
telephoniques mobile ou fixe de type GSM, RTC, RNIS ou IP. L'abonne ENUM emet 
a Tetape 200 un SMS formate (ex: N^E.164 + pseudonyme + mot de passe + requete) 
5 comme specific par le foumisseur de service. ENUM (30) depuis un terminal fixe RTC 
(4) ou RNIS (2) connecte sur le r^seau public ou derrifere le PABX (3) ou un terminal 
mobile (6) de type GSM, ou depuis un terminal IP (7), a destination du module SMS 
(58) de la presente invention. Ce dernier transmet le SMS ^ Tetape 201 vers le module 
script ENUM (75). Ces informations sont foumies a I'etape 202 au module 
10 d'authentification (73) qui interroge a I'^tape 203 la base de donn^es locale ou distante 
(via ime interface ODBC par exemple) en operant une recherche sur le numero 
ENUM E. 164. Celle-ci foumit a Tetape 204 les informations correspondantes au 
module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de 
passe saisis par le client ENUM dans le SMS avec les informations d'authentification 
15 contenues dans la base de donnees. En cas de concordance, le module 
d'authentification (73) ordonne a Tetape 205 au module script ENUM (75) de trailer la 
requete contenue dans le SMS. Le script ENUM (75) detecte qu'il s'agit d'une 
: . . commande de lecture du profil ENUM. Par consequent, le script ENUM (75) emet 
une demande d'interrogation a Petape 206 au module de gestion protocole DNS £62) 
, 20 en foumissant en .argument Tadresse E.164 de Tabonne ENUM transformee.;sous 
forme de domaine (transformation du numero de telephone EJ64 de type 
33296053859 en (9.5.8.3. 5.0.6.9.2.3.3. el 64.arpa). Le module de gestion. protocole 
DNS (62) qui joue le rdle classique d'un RESOLVER interroge (etape 207) a I'aide 
d'une requete (DNS Query) le serveur DNS de niveau 0, puis le serveur DNS de 
25 niveau 1, a moins que les informations ne soient deja dans son cache suite a une 
consultation precedente de ces serveurs. Pour gagner en efficacite, les donnees d'un 
. serveur DNS sont chargees dans la m6moire vive du serveur (31). Si rabonne ENUM 
est efiectivement enregistre dans le serveur DNS (31) du foumisseur de service 
^ ENUM (30) alors le module protocole DNS (32) retoume a Tetape 208 les 
. 30 enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) 
se charge ensuite de les retransmettre vers le module script ENUM (75) a Fetape 209, 
Ce dernier analyse et interprete les enregistrements NAPTR et genere un texte 
relativement synthetique et comprehensible par l'abonne ENUM du type "PI: Tel= 
0296053859, P2: Tel=0686 166924, P3: eMail= 
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bertranddupont@rd.franceteleconi.com . P4: urI=www.bertranddupont,fr, etc.)- Ce 
texte est envoye a I'etape 210 vers le module d'envoi de SMS (58) qui envoie le SMS 
(a I'etape 211) vers le terminal telephonique a rorigine de la requete (utilisation du 
Num^ro de Tappelant). 

L'abonn^ ENUM emet k I'etape 250 un message SMS formate (ex: N*" E.164 + 
pseudonyme + mot de passe + type de requete=- ECR: Pl:tel=0686 166924, 
P2:email=bertrand.dupont@rd.francetelecomxom) comme specific par ie foumisseur 
de service ENUM (30) depuis un terminal fixe RTC (4) ou RNIS (2) connecte sur le 
reseau public ou derriere le PABX (3) ou un terminal mobile (6) de type GSM, ou 
depuis un terminal IP (7) k destination du module SMS (58) de la presente invention. 
Ce dernier transmet le message SMS a Tetape 251 vers le module script ENUM (75). 
Ces informations sont foumies a I'etape 252 au module d'authentification (73) qui 
interroge a Tetape 253 la base de donnees locale ou distante (via une interface ODBC 
par exemple) en operant une recherche sur le numero ElsTUM E.164, Celle-ci foumit a 
Fetape 254 les informations correspondantes au module tfauthentification (73) qui se 
charge de comparer ie pseudonyme et le mot de passe saisis par le client ENUM dans 
le message SMS avec les informations d'authentification contenues dans la base de 
donnees. En cas de concordance, le module d'authentification (73) en avertit le module 
script ENUM (75) qui traite alors la requete contenue dans le SMS. Le script ENUM 
(75) detecte qu'il s'agit d'une commande de mise a jour du profil ENUM avec des 
arguments. Le script ENUM (75) verifie la syntaxe de la commande et, si elle est 
correcte, emet une demande de mise a jour ^ I'etape 256 au module de gestion de 
protocole DNS (62). Ce dernier emet une commande DNS UPDATE a Fetape 257 a 
destination du module protocole DNS (32) du serveur DNS (31) du foumisseur de 
service ENUM (30). II est rappele que Fadresse IP de ce dernier est stockee dans la 
base de donnees (70) et qu'elle est retrouvee a partir du numero E.164 de I'abonne - 
ENUM. Le module protocole DNS (32) met a jour rinformation dans la memoire vive 
du serveur (31) et demande la mise a jour de la base de donnees (33) qui est 
generalement un fichier texte a plat. Le protocole DNS gere le numero de 
modification dans ce fichier de maniere a ce que le/les serveur(s) DNS secondaire(s) 
puisse(nt) recharger lui/eux-meme(s) cette modification a des intervalles de temps 
predefinis. Le serveur (31) confirme la mise a jour a Petape 259, ce qui se traduit par 
une reponse a la requete de demande de mise a jour a Fetape 260. Le script ENUM 
(75) intercepte a Fetape 261 le code retour de cette reponse puis genere a Fetape 262 
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le message de confirmation/infirmation de prise en compte de la modification avant de 
I'envoyer au module d'envoi de SMS (58) qui se charge d'envoyer le SMS a I'etape 
263 vers le terminal telephonlque a I'origine de la requSte (utilisation du numero de 
I'appelant). 

La Fig. 6 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par le web h partir d'un terminal disposant 
d'un navigateur web (8). 

L'abonne ENUM demande a I'etape 300 le t^lechargement de la page web 
d'accueil du service de gestion du profil ENUM. Celle-ci est retoumee a I'etape 301 
par le serveur web (63) de la pr^sente invention. Cette page web affiche un formulaire 
d'authentification a l'abonne ENUM. Celui ci saisit son numero E.164 puis son 
pseudonyme et son mot de passe. Ces informations sont transmises a I'etape 3i)2 au 
serveur web (63) qui lui meme les transmet a I'etape 303 au module d'authentification 
(73). Le module d'authentification (73) interroge a I'etape 304 la base de donn^es 
locale ou distante (via une interface ODBC par exemple).en operant une recherche sur 
le .num6ro ENUM E.164. . Celle-ci. foumit ^ I'etape 305 les informations 
correspondantes au module d'authentification (73) qui se charge, de comparer le 
pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire v?eb et 
les informations d'authentification contenues dans la base de donnees. En <^s de 
concordance, le module d'authentification (73) notifie a I'etape 306 le module serveur 
web (63) que I'authentification est r^ussie. Celui-ci 6met a I'dtape 307, a destination 
du module script ENUM (75), une .requ6te de lecture du profiJ ENUM. Par 
consequent, le script ENUM (75) emet une demande d'interrogation a I'etape 308 au 
module protocole DNS (62) en foumissant en argument I'adresse E.164 de l'abonne 
ENUM transformee sous forme de domaine (transformation du numero de telephone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole 
DNS (62) qui joue le rdle classique d'un RESOLVER interroge (a I'etape 309) apres 
avoir verifie si les informations ne, sont pas presentes dans son cache suite a une 
consultation precedente, a I'aide. du protocole standard DNS (requele DNS Query) 
suocessivement le serveur DNS de niveau 0, le serveur de DNS de niveau I, puis le 
serveur DNS de niveau 2. Pour gagner en efficacite, les donnees d'un DNS sont 
charg^es dans la m^moire vive du serveur DNS (31). :Si l'abonne ENUM est 
effectivement enregistre.dans le DNS (31) du foumisseur de service ENUM (30), le 
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module protocole DNS (32) retoume a Tetape 310 les enregistrements NAPTR 
correspondants au module protocole DNS (62). Ce dernier les retransmet vers le 
module script ENUM (75) a Fetape 311 qui interprete les enregistrements NAPTR et 
genere un texte relativement synthetique et comprehensible par Tabonne ENUM du 
5 type: 



Service de priorite 1 Tel: 0296053859 

Service de priorite 2 Tel: 06861 66924 

Service de priorite 3 Mail: b.dupont@rd.ft.com 

10 Service de priority 4 Web : www-.bertranddupont.fn 



Ce texte est envoye a I'etape 312 vers le module serveiu* web (63) qui t^lecharge une 
page w^eb munie de ces informations k I'etape 313 vers le terminal Web (8) de 
Tabonne ENUM. 
15 . 

La page web presentee a Tabonne ENUM permet via une interface graphique 
adaptee d'operer des modifications de profil ENUM courant: modification des 
• priorites, ajout de service, suppression de service, modification des attributs d'un ' 
service, etc. La demande en modification est emise a Tetape 350 a destination du 

20 ^rveur web (63). Ce dernier transmet a Tetape 351 la requete vers le module script 
ENUM (75) qui se charge de formater la requete conformement aux entrees NAPTR 
decrites par le protocole ENUM. Le script ENUM (75) emet alors une demande de 
mise a jour a P^tape 352 au module protocole DNS (62). Ce dernier emet une 
commande DNS UPDATE a Fetape 353 a destination du module protocole DNS (32) 

25 du serveur DNS (31) du foumisseur de service ENUM (30). II est rappele que 
I'adresse IP de ce dernier est stockee dans la base de donnees (70) et qu*elle est • 
retrouvee a partir du numero EJ64 de Fabonne ENUM. Le module protocole DNS 
(32) met a jour rinformation dans la memoire vive du serveur (31) et demande la mise 
a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 

30 protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette 
modification a des intervalles de temps predefinis. La base de donnees (33) confirrne 
la mise a jour a Tetape 355, ce qui se traduit par une reponse a la requete de demande 
de mise a jour a I'etape 356. Le script ENUM (75) intercepte a Fetape 357 le code 
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retour de cette reponse puis genere a J'etape 358 le message de 
confimiation/infinnation de prise en compte de la modification avant de Tenvoyer au 
serveur web (63) qui se charge de formater la page web de resultat avant de la 
tel6charger a T^tape 359 vers le terminal web (8). 

5 

La Fig. 7 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM a partir d'un Minitel. 

L*abonn6 ENUM se connecte au service Minitel en utilisant la fonction PA VI 
(Point d'Acces Videotex) du reseau de France Telecom (appel par exemple du 3615 

10 code ENUM-FT). Le terminal minitel (5) entre alors en session avec le serveur minitel 
(57) a I'etape 400. Ce dernier active a Tetape 401 le module script ENUM (75) de la 
pr^sente invention qui genere alors la page d'accueil du service a Tetape 402 et qui est 
telechargee a I'etape 403 sur le terminal Minitel (5) de Tabonne ENUM . Cette. page 
Minitel affiche un formulaire d'authenttfication a Tabonne ENUM. Celui-ci saisit son 

15 numero ENUM E.164 puis son pseudonyme et son mot de passe. Ces informations 
sont transmises a Tetape 404 au serveur Minitel (57) qui lui meme les transmet a 
I'etape 405 au module script ENUM (75). Ce dernier redirige la requete a retape^406 
. vers le module d'authentification (73). Le module d'authentification (73) interrgge a 
Tetape 407 la base de donndes locale ou distante (via une interface ODBC par 

20 exemple) en operant une recherche sur le numero ENUM E.164. A Tetape 4(^^ les 
informations d'authentification de la base der donnees sont transmises au module 
d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis 
dans le formulaire Minitel. En cas de concordance, le module d'authentification (73) 
notifie a I'etape 409 le module script ENUM (75) que Fauthentification est .reussie. Le 

25 module script ENUM (75) emet alors une demande d*interrogation a I'etape 410 au 
module protocole DNS (62) en foumissant en argument Tadresse E.164 de Tabonne 
ENUM ,transformee sous forme de domaine (transformation du numero de telephone 
E.164 de type 33296053859- en 9.5.8.3.5.0.6.9.2.33.el64.arpa). Le module. protocole 
DNS (62) qui joue le role classique d'un RESOLVER interroge (etape 411), apres 

30 avoir verifie si les informations ne sont pas presentes dans son cache suite a une 
consultation precedente, a Taide du protocole standard DNS (requete DNS Query) 
successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le 
serveur DNS de niveau 2. De preference^ pour gagner en efficacite, les donnees d'un 
DNS sont chargees dans Ja memoire vive du. serveur DNS (31). Si Tabonn^ ENUM est 
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effectivement enregistre dans le serveur DNS (31) du foumisseur de service ENUM 
(30), le module protocole DNS (32) retoume (a Tetape 412) les enregistrements 
NAPTR correspondants. Le module de protocole DNS (62) se charge de les 
retransmettre vers le module script ENUM (75) a Tetape 413. Ce dernier analyse et 
interprete les enregistrements NAPTR et genere un texte relativement synthetique et 
comprehensible par Tabonne ENUM du type: 

Service de priorite 1 Tel: 0296053859 

Service de priorite 2 Tel: 0686 1 66924 

Service de priorite 3 Mail: b.dupont@.rd.ft .com 

Service de priorite 4 Web vsrww.bertranddupont fr, 

Ce texte est envoye a Tetape 414 vers le module serveur videotex (57) qui se charge 
de telecharger a Fetape 415 vers le terminal Minitel (5) de Fabonne ENUM . 

La page videotex presentee a Tabonne ENUM permet via une interface adaptee 
d'operer des modijScations sur le profil ENUM courant: modification des priorites, 
ajout de service, suppression de service, modification des attributs d'un service; etc. La 
requete de mise a jour du profil ENUM est emise a Fetape 450 a destination du 
serveur videotex (57). Ce dernier transmet a Fetape 451 la requete vers le module 
script ENUM (75) qui se charge de formater la requete conformement aux entrees 
NAPTR decrites par le protocole ENUM. Le script ENUM (75) emet alors une 
demande de mise a jour a Fetape 452 au module protocole DNS (62), Ce dernier 6met 
une commande DNS UPDATE a Fetape 453 a destination du module protocole DNS 
(32) du serveur DNS (31) du foumisseur de service ENUM (30). II est rappele que 
Fadresse IP de ce dernier est stockee dans la base de donnees (70) et qu'elle est 
retrouvee a partir du numero E.164 de I'abonne ENUM. Le module protocole DNS 
(32) met a jour I'information dans la memoire vive du serveur (3 1) et demande la mise 
a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 
protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette 
modification a des intervalles de temps predefinis. La base de donnees (33) confirme 
la mise a jour a Fetape 455, ce qui se traduit par une reponse a la requete de demande 
de mise a jour a Fetape 456. Le script ENUM (75) intercepte a Fetape 457 le code 
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retour de cette reponse puis g^nere a Tetape 458 le message de 
confirmation/infirmation de prise en compte de la modification avant de I'envoyer au 
serveur videotex (57) qui se charge de fomiater la page videotex de resultat avant de 
la telecharger a I'etape 459 vers le terminal Minitel (5). 

5 

La Fig. 8 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par eMail a partir d'un terminal disposaht 
d'un client eMail (8). 

L'abonne ENUM emet un eMail formate k Tetape 500 a destination du serveur 
10 eMail (61). La commande ENUM est par exemple passee dans Tadresse eMail 
destinataire: 

e 1 64-3 3296053 859-login-dupont-password- 1 234-requete 
lire@gestion,enum.fi'ancetelecom.com 

15 

Le modvile script ENUM (75) dispose d'un client eMail qui vient regulierement 
scruter le serveur eMail (61). Lorsque le module script ENUM (75) refoit a Tetape 
501 un eMail comme indique ci-dessus, il r^cupfere, sort dans I'entete, soit daps le 
corps de I'eMail, les arguments foumis puis les transmet a Tetape 502 vers le module 

20 d'authentification (73). Le module d'authentification (73) interroge a Tetape 5<p3 la 
base de donn^es locale ou distante (via une interface ODBC par exemple) en 
eflfectuant une recherche sur le numero ENUM E.164. Celle-ci foumit a Tetape 504 
les informations d'authentification correspondantes au module d'authentification (73) 
qui les compare au pseudonyme (login id) et au mot de passe (password) foumis par 

25 le client ENUM dans TeMail. En cas de concordance, le module d'authentification 
(73) en avertit le module script ENUM (75) a Tetape 505. Par consequent, le script 
ENUM (75) emet une demande d'interrogation a Tetape 506 au module de gestion de 
protocole DNS (62) en fournissant en argument I'adresse E.164 de Tabonne ENUM 
transform^e en nom de domaine (transformation du numero de telephone E.164 de 

30 type 33296053859 en 9.5. 8. 3. 5.0.6.9.2. 3.3.el64,arpa), Le module de gestion de 
protocole DNS (62) qui joue le role classique d'un RESOLVER interroge (etape 507), 
si.toutefois les informations ne sont pas deja presentes dans son cache suite a une 
consultation precedente, selon le protocole standard DNS (requete DNS Query) 
successivement le serveur DNS de niveau, 0, le serveur de DNS de niveau 1, puis le 
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serveur DNS de niveau 2 par la pile de protocole DNS (32). De preference, pour 
gagner en eflBcacite, les donnees d'un DNS sont chargees dans la memoire vive du 
serveur DNS (31). Si Tabonne ENUM est efFectivement enregistre dans le DNS (31) 
du foumisseur de service ENUM (30) alors le module de gestion de protocole DNS 
5 (32) retoume a Tetape 508 les enregistrements NAPTR correspondants. Le module de 
gestion de protocole DNS (62) se charge de les retransmettre vers le module script 
ENUM (75) a I'etape 509. Ce dernier analyse et interpr^te les enregistrements* 
NAPTR et genere un texte relativement synthetique et comprehensible par Tabonne 
ENUM du type: 

10 

Service de priorite 1 
Service de priorite 2 
Service de priorite 3 
Service de priorite 4 

15 

Ce texte est expedie (etape 510) sous forme d'eMail par le iogiciel client eMail 
integre dans le module script ENUM vers le module serveur eMail (61) qui se charge 
de Tenvoyer vers Tabonne ENUM. 

20 L'abonn6 ENUM qui souhaite modifier son Profil ENUM envoie un eMail 

formate a Tetape 550 a destination du serveur eMail (61)* La commande ENUM est 
par exemple passee dans I'adresse eMail destinataire, par exemple: 
el64-33296053859-login-dupont-password-1234-requete-ecrire-Pl-tel-0296053859- 
P2-tel-0686 1 66924-P3-fex-0296050242@gestion.enum.fi'ancetelecom.com 

25 

Le client eMail du module script ENUM scrute le serveur eMail (61). Lorsque le , . 
module script ENUM re9oit (en 551) un eMail comme indique ci-dessus, il recupere, 
soit dans Tentete, soit dans le corps de TeMail, les arguments foumis puis les transmet 
a Tetape 552 vers le module d'authentification (73). Le module d'authentification (73) 
30 interroge a Tetape 553 la base de donnees locale ou distante (via une interface ODBC 
par exemple) en operant une recherche sur le numero ENUM E.164. Celle-ci foumit a 
I'etape 554 les informations d'authentification correspondantes et le module 
d'authentification (73) les compare au pseudonyme et au mot de passe fournis dans 
TeMail. En cas de concordance, le module d'authentification (73) en avertit le module 



Tel: 0296053859 

Tel: 0686166924 

Mail: b . dupontt^xd . ft . com 

Web w^w.bertranddupont.fn 
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script ENUM (75) a Tetape 555. Ce dernier formate la requete conformement aux 
entrees NAPTR decrites par le protocole ENUM, Le script ENUM (75) transmet alors 
une demande de mise a jour a I'etape 556 au module de gestion de protocole DNS 
(62) qui emet une commande DNS UPDATE a I'etape 557 a destination du module 

5 protocole DNS (32) du serveur DNS (31) du foumisseur de service ENUM (30). II est 
rappele que I'adresse IP de ce dernier est stockee dans la base de donnees (70) et 
qu'elle est retrouvee a partir du numero E.164 de rabonne ENUM. Le module 
protocole DNS (32) met a jour rinformation dans la memoire vive du serveur (31) et 
demande la mise a jour de la base de donnees (33) qui est generalement un fichier 

10 texte a plat. Le protocole DNS gere le numero de modification dans ce fichier de 
maniere a ce que le/Ies serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux- 
meme(s) cette modification a des intervalles de temps predefinis. La base de donnees 
(33) confirme la mise a jour a I'^tape 559, ce qui se traduit par une reponse a la 
requete de demande de mise a jour a Tetape 560. Le module script ENUM_(7 5) 

15 intercepte a I'etape 561 le code retour de cette reponse puis genere le message de 
. : confirmation/infirmation de prise en compte de la modification. Ce message est 
expedie (a r6tape 562) sous forme d'eMail par le logiciel client integre dajis le 
module script ENUM au serveur eMail (61). Ce dernier envoie a I'etape 563 I'eMail 
en question a I'abonne ENUM qui peut le consulter sur son terminal (8). 

20 : . . . 

La Fig. 9 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par lUU (Information d'Usager^a Usager) a 
partir d'lm terminal RNIS (2). 

L'abonne ENUM emet a I'etape 600 depuis son terminal RNIS (2) un appel 

25 telephonique contenant I'element d'information lUU vers Tinterface RNIS (51). II faut 
rappeler que le champ lUU est actuellement limite a une taUle de 32 caracteres. La 
. commande ENUM qui est inser^e dans le champ lUU ne pourra done agir que sur un 
service ENUM a la fois. Par exemple: GetPI-33296053859*dupont#123456: cette 
requete permet de recuperer les attributs du service ENUM de priorite 1 . 

30 L'automate d'appel (52) . transmet . a I'etape 601 le message de demande 

d'etablissement d'appel au module lUU (53) qui va extraire la commande lUU. 
L'automate d'appel (52) emet a I'etape 652 le message Alerte a destination de Tabonne 
ENUM de maniere a s'autoriser un minimum de temps (temporisation du protocole 
RNIS avant d'envoyer^yn message de deconnexion). Le module IUU-(53) transmet la 
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commande ENUM a Tetape 603 vers le module script ENUM (75). Ce dernier 
recupere les arguments ENUM foumis puis les transmet a Tetape 604 vers le module 
d'authentification (73). Le module d'authentification (73) interroge a I'etape 605 la 
base de donnees locale ou distante (via une interface ODBC par exemple) en operant 
5 une recherche sur le numero ENUM E.164. Celle-ci foumit a Tetape 606 les 
informations d'authentification correspondantes au module d'authentiJBcation (73) qui 
les compare avec * le pseudonyme et le mot de passe foumis par le client ENUM dans 
riUU. En cas de concordance, le module d*authentification (73) en avertit le module 
script ENUM (75) a Tetape 607, Par suite, le module script ENUM (75) emet une 

10 demande d'interrogation a Tetape 608 au module de gestion de protocole DNS (62) en 
foumissant en argument Fadresse E.164 de Tabonne ENUM transformee sous forme 
de domaine (transformation du numero de telephone E.164 de type 33296053859 en 
9,5. 8.3.5.0.6.9. 2. 3. 3,el64.arpa), Le module de gestion de protocole DNS (62) qui joue 
le role classique d*un RESOLVER pent interroger (a I'etape 609), apres avoir verifie si 

1 5 les informations ne sont pas deja dans son cache suite a une consultation precedente, a 
Taide du protocole standard DNS (requete DNS Query) le DNS niveau 0 puis le DNS 
niveau 1, puis le DNS niveau 2 via son module de protocole DNS (32). De 
preferencje, pour gagner en efiBcacite, les donnees d'un serveur DNS sont chargees 
dans la memoire vive du serveur (31). Si Fabonne ENUM est ejSectivement enregistre 

20 dans le DNS (31) du foumisseur de service ENUM (30), la pile de protocole DNS (32) 
retoume a Tetape 610 les enregistrements NAPTR correspondants au module de 
gestion protocole DNS (62) qui se charge de les retransmettre vers le module script 
ENUM (75) a I'etape 611. Ce dernier analyse et interprete les enregistrements 
NAPTR et en fonction du service demande dans la commande lUU genere un texte 

25 relativement synthetique et comprehensible par Tabonnd ENUM du type: 

Service PI: Tel:0296053859 

Ce texte est envoye a I'etape 612 vers le module lUU (53) qui se charge de 
30 formater un message de deconnexion avant de I'envoyer a Fetape 613 au module 
automate d'appel (52). Ce dernier genere le message de deconnexion RNIS qui 
contient Telemenl d'information lUU et qui est done transmis a I'etape 614 via le 
reseau RNIS au terminal (2) de Tabonne ENUM. Ce dernier peut visualiser FIUU sur 
raflRcheur de son terminal RNIS (2). 
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L'abonne ENUM qui souhaite modifier son profil ENUM emet a Tetape 650 
depuis son terminal RNIS (2) vm appel tel^phonique contenant Telement d'information 
lUU vers I'interface RNIS (51). Par exemple: DeIP3-33296053859*dupont# 123456: 
cette requSte permet de supprimer le service ENUM de priorite 3. 
5 L'automate d'appel (52) transmet a T^tape 651 un message de demande 

d'etablissement d'appel au module lUU (53) qui extrait la commande lUU. L'automate 
d'appel (52) emet a Tetape 652 le message Alerte a destination de I'abonn^ ENUM de 
manifere a s'autoriser im minimum de temps (temporisation du protocole RNIS avant 
d'envoyer un message de deconnexion). Le module lUU (53) transmet la commande 

10 ENUM a r^tape 653 vers le module script ENUM (75). Ce demier recupere les 
arguments foumis puis les transmet a Tetape 654 vers le module d'authentification 
(73)* Le module d*authentification (73) interroge a T^tape 655 la base de donn^es 
locale ou distante (via une interface ODBC par exemple) en operant une recherche sur 
le numero ENUM E.164. Celle-ci foumit a Tetape 656 les infommtions 

•15 d'authentification correspondantes au module d'authentification (73) qui les compare 
au pseudonyme et au mot de passe foumis par le client ENUM dans I'lUU. En cas de 
concordance, le module d'authentification (73) en avertit le module script ENUM (75) 
a Tetape 657. Etant domi6 que la modification ne porte pas sur Tensemble du profil, le 
. . script ENUM (75) emet d'abord une demande d'interrogation (a Tetape 65j8) au 

20 module de gestion de protocole DNS (62) en foumissant en argument radresse?^164 
de rabonn6 ENUM transformee sous forme de domaine (transformation du. numero de 
telephone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.33xl64.arpa). Le module 
de gestion de protocole DNS (62), qui joue le role de RESOLVER, peut interroger (a 
Tetape 659), apres avoir verifie si les informations ne sont pas deji dans son cache 

25 suite a une consultation precedente, a Taide du protocole standard DNS (requete DNS 
Query) le DNS niveau 0, le DNS niveau 1 puis le DNS niveau 2 via son module de 
protocole DNS (32). Pour gagner en eflScacite, les donnees d'un DNS sont chargees 
dans la memo ire vive du serveur (31). Si Tabonne ENUM est effectivement enregistre 
dans le DNS (31) du foumisseur de service ENUM (30), le module protocole DNS 

30 (32) retoume a I'etape 660 les enregistrements NAPTR correspondants au module de 
gestion de protocole DNS (62). Ce demier se charge de les retransmettre vers le 
module script ENUM (75) a Tetape 661. Le script ENUM (75) emet alors une 
demande de mise a jour en tenant compte de la modification demandee dans le champ 
lUU a Tetape 662 au module protocole DNS (62). Ce demier 6met une commande 
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DNS UPDATE a Tetape 663 a destination du module protocole DNS (32) du serveur 
DNS (31) du foumisseur de service ENUM (30). II est rappel6 que Tadresse IP de ce 
dernier est stockee dans la base de donnees (70) et qu'elle est retrouvee a partir du 
numero E.164 de Tabonne ENUM. Le module protocole DNS (32) met a jour 
5 rinformation dans la memoire vive du serveur (31) et demande la mise a jour de la 
b^e de donnees (33) qui est generalement un fichier texte a plat, Le protocole DNS 
gere le numero de modification dans ce fichier de maniere a ce que le/les serveurs 
DNS secondaire(s) puisse(nt) recharger lui/eux-m6me(s) cette modification a des 
intervalles de temps predefinis. La base de donnees (33) confimie la mise a jour a 

10 Tetape 665, ce qui se traduit par ime reponse a la requete de demande de mise a jour a 
I'etape 666. Le script ENUM (75) intercepte a I'etape 667 le code retour de cette 
reponse puis genere a Tetape 668 le message de confirmation/infirmation de prise en 
compte de la modification. Ce message est envoye a Tetape 668 vers le module lUU 
(53) qui se charge de formater un message de deconnexion avant de I'envoyer a Tetape 

15 669 au module automate d'appel (52). Ce dernier genere a Petape 670 le message de 
deconnexion RNIS qui contient Telement d'information lUU et qui est done transmis 
via le reseau RNIS vers le terminal (2) de Tabonne ENUM. Ce dernier pent visualiser 
riUU sur i'afficheur de son terminal RNIS (2). . . . . , 

20 La Fig. 10 illustre schematiquement la procedure d'acces au service de 

consultation et de modification automatique d^un profil ENUM a partir d'une session 
web. La tache consistant a modifier manuellement un profil ENUM pent vite devenir 
d^Ucate et repetitive. Un automate (dit automate de configuration) est alors utilise 
pour efifectuer une modification automatique du profil ENUM en fonction du temps 

25 et/ou d'autres parametres. Parmi ces autres parametres, la localisation de Pabonne 
.pent etre retenue si elle est connue du systqme (50). 

L'abonne ENLTM demande a Petape 700 le telechargement de la page web 
d'accueil du service de gestion du profil ENUM. Celle-ci est retoumee a Petape 701 
par le serveur web (63) de la presente invention. Cette page web affiche un formulaire 

30 d'authentification a Tabonne ENUM. Celui-ci saisit son numero ENUM E.164 puis 
son login et mot de passe. Ces informations sont transmises a Tetape 702 au serveur 
web (63) qui lui meme les transmet (a Tetape 703) au module d'authentification (73). 
Le module d'authentification (73) interroge (a I'etape 704) la base de donnees locale 
ou distante (70) (via une interfiice ODBC par exemple) en operant une recherche sur 
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. le numero ENUM E.164. Celle-ci foumit a Tetape 705 les informations 
d'authentification correspondantes au module d'authentification (73) qui les compare 
avec le pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire 
web. En cas de concordance, le module d'authentification (73) notifie a Petape 706 le 
5 module serveur web (63) que Tauthentificatipn est reussie. Celui-ci emet a I'dtape 707 
a destination du module script ENUM (75) une requete en lecture de la configuration 
automatique pour ce profQ ENUM. Le module script ENUM (75) interroge a I'etape 
708 la base de donnees (70) en fournissant en arguments le numero E.164 de Tabonne 
ENUM. La base de donnees (70) retoume a I'etape 709 le programme de gestion 
10 automatique du profiJ au module script ENUM(75). Ce dernier met en forme les 
informations, par exemple: 

Lundi au Vendredi: de 08:30 a 19:00 
0296053859 

0686166924 J 
bertrand.dupont@rd.francetelecom.com 
0296050242... , . 

Lundi au Vendredi: de 19:00 a 08:30 
20 PI Tel 0296916404 .Hi 
P2 . eMail bertrand.dupont@rd.franceteIecom.com . 

Samedi et Dimanche: de 00.00 a 23:59 
PI . Tel 0296916404 
25 P2 Tel 0686166924 

P3 eMail b,dupont@Avanadoo.fr 

Le module script ENUM (75) transmet les informations formatees a I'etape 710 
au serveur web (63) qui se charge de telecharger la .page web contenant les 
30 informations en clair du programme de configuration du profil ENUM,sur.le terminal 
web (8) de Tabonne ENUM. . . 

Cette page web permet la modification du programme de configuration 
automatique du profil ENUM: modification des horaires, gestion des jours feries, 
ajout-suppression de se^ce, modifications des attributs des services, etc. L'abonn6 



PI Tel 
15 P2 . Tel 

P3 . eMaU 
P4 fax 
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ENUM valide la modification du programme a I'etape 750. Le serveur Web (63) 
transmet ces informations a I'etape 751 vers le module script ENUM (75). Ce demier 
extrait les informations, les met en forme selon un format defini avant de les ^rire 
dans la base de donn6es (70), a T^tape 752. Celle-ci prend en compte Tenregistrement 
du programme et le confirme h Yitape 753 au module script ENUM (75). Ce demier 
notifie au serveur web (63) k I'etape 754 la prise en compte de la modification de 
I'automate de configuration du profil ENUM. Le serveur telecharge a I'etape 755 la 
page web de confirmation de la modification sur le terminal web (8) de Tabonne 
ENUM. 

La Fig. 1 1 fllustre la procedure de mise a jour automatique par I'automate de 
configuration des profils ENUM ainsi que la procedure optionnelle de notification de 
changement de profU vers I'abonne ENUM. 

L'automate de configuration (74) scmte r6guUerement a I'etape 800 la base de 
donnees (70) pour verifier s'il y a une modification programmee a reaUser (en fonction 
du jour et de ITieure courants). Si une modification est programmee alors les 
parametres de configuration sont retoumes a I'^ape 801. L'automate de configuration 
(74) emet une demande ^interrogation §i I'etape 802 au module de ge,stion de 
protocole DNS (62) en foumissant en argument I'adresse E.164 de I'abonn^ ENUM 
dont le profil est a modifier, transform^ sous forme de nom de domaine 
(transformation du num^ro de telephone E.164 de type 33296053859 en 
9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui 
joue le role d'un RESOLVER peut interroger I'etape 803), si toutefois les 
informations ne sont pas deja dans son cache suite a une consultation precedente, a 
i'aide du protocole standard DNS (requete DNS Query), le serveur DNS niveau 0, le 
. serveur , DNS niveau 1, puis le serveur DNS niveau 2 via son module de protocole 
DNS (32). De preference, pour gagner en efficacite, les donnees d'un DNS sont 
chargees dans la memoire vive du serveur DNS (31). Si I'abonne ENUM est 
efifectivement enregistre dans le DNS (31) du fournisseur de service ENUM (30) alors 
le module protocole DNS (32) retourae a I'etape 804 les enregistrements NAPTR 
correspondants au module protocole DNS (62). Ce demier les retransmet vers 
I'automate de configuration (74) qui consulte alors (etape 806) la base de donnees 
(70) afin de recuperer les modifications a operer sur le profil ENUM. La base de 
donnees retourne (etape 807) le profil k appliquer au module automate de 
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configuration (74). Si une modification est effectivement necessaire (le profil a pu 
entre temps etre raodifie manuellement), T automate de configuration determine les 
modifications a apporter aux enregistrements NAPTR et emet une demande de mise a 
jour a Tetape 808 au module de gestion de protocole DNS (62). Ce dernier emet une 
5 commande DNS UPDATE a Petape 809 h destination du module protocole DNS (32) 
du serveur DNS (31) du foumisseur de service ENUM (30). II est rappele que 
I'adresse IP de ce dernier est stock^e dans la base de donnees (70) et qu'elle est 
retrouvee a partir du numero E.164 de Tabonne ENUM. Le module protocole DNS 
(32) met a jour rinformation dans la memoire vive du serveur (31) et demande la mise 

10 a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 
protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
leAes serveurs DNS secondaire(s) puisse(nt) recharger lui/eux -meme(s) cette 
modification a des intervaUes de temps predefines. La base de donn6es (33) confirme 
la mise a jour a Tetape 81 1, ce qui se traduit par une reponse a la requete de dernande 

15 de mise a jour a Tetape 812. Le module automate de configuration (74) intercepte a 
Tetape 813 le code retour de cette reponse puis genere a Tetape 814 une demande 
d'ecriture dans la base de donnees (70) pour alimenter le journal des modifications. La 
base de donnees (70) confirme Tecriture de I'evenement de modification automatique 
du profil a I'etape 815. 

20 Si le service de mise a jour automatique a et6 configure pour notifi|r^ les 

modifications automatiques de profil ENUM, Tautomate de configuration notifie la 
mise a jour selon un ou plusieurs des modes suivants : 

o dans le cas ou la notification est en mode vocal, I'automate de configuration 
25 (74) notifie Tautomate d'appel (52) a Tetape 820, ce qui se traduit par un 

appel telephonique vers un telephone fixe RTC (4), ou RNIS (2), ou IP (7) ou 
vers un telephone mobile (6). Les informations et adresses de notification 
sont stockees dans la base de donnees (70). L'abonne ENUM repond a cet 
appel telephonique a Tetape 822 ou I'appel est aiguille vers sa messagerie 
30 vocale. Le module de synthese vocale (55) ou le module de diflusion de 

fichiers vocaux (56) diflRase.a I'etape 823 la notification de la modification de 
profil ENUM, par exemple: "bonjour, votre profil ENUM 33296053859 a ete 
mis a jour aujourd*hui k 19:00 comme suit: service telephonique vers 
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0296053859 puis service telephonique vers 0686166924 puis service eMail 
vers hertrand.du pnnti'a.wanadoo.fr"; 

o dans le cas ou la notification est en mode SMS, I'automate de configuration 
(74) avertit le module SMS (58) a I'etape 830 en foumissant le texte du SMS 
par exemple du type: "Modification de votre profil ENUM 33296053859 le 
21/03/2002 a 09:00: tel:0296053859, tel:0686166924,fex:0296050242". Le 
module SMS (58) transmet a l'6tape 840 ce message SMS a destination du 
terminal telephonique mobile ou fixe, tel que configure dans la base de 
dorm6es (70) ; 

o dans le cas ou la notification est en mode eMail, I'automate de configuration 
(74) notifie la mise a jour au serveur eMaU (61) (etape 850) a I'aide d'un 
eMail contenant un texte du type: "Modification de votre profil ENUM 
33296053859 le 21/03/2002 a 09:00: tel:0296053859, tel:0686 166924, 
fax:0296050242". A cette fin, I'automate de configuration dispose d'un cUent 
eMail. Le serveur eMail (61) transmet ensuite a I'^tape 860 I'eMail en 
question a I'adresse eMaU stockee dans la base de donnas (70) ; 

o dans le cas ou la notification est en mode fex, Fautomate de configuration 
(74) notifie au module fex (59) k I'^tape 870 en foumissant le texte du fex qui 
pourrait Hrc de type: "Modification de votre profil ENUM 33296053859 le 
21/03/2002 a 09:00: t61:0296053859, t61:0686166924,fex:0296050242". Le 
module fex (59) transmet k I'^tape 880 ce fex a destination du terminal fex 
(9) configure dans la base de donndes (70). 

La Fig. 12 illustre un exemple de procedure de consultation de profil ENUM 
lorsque ce dernier est stocke dans un annuaire LDAP. L'exemple donne en Fig. 12 
illustre une consultation via un ordinateur individuel mais il est clair que la 
consultation peut etre reaUsee au moyen des autres types de terminaux precedemment 
envisages. Ce type de service pourrait notamment Stre propose par des entreprises qui 
souhaiteraient ofifrir I'acces a un service ENUM a toute ou partie de leurs employes. 

L'abonne ENUM demande a I'etape 900 le telechargement de la page web 
d'accueil du service de gestion du profil ENUM. CeUe-ci est retoumee a I'etape 901 
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par le serveur web (63) du systeme (50). Cette page web affiche un formulaire 
d'authentification a rabonn6 ENUM. Celui-ci saisit son numero ENUM E.164 puis 
son pseudonyme et son mot de passe. Ces informations sort transmises k T^tape 902 
au serveur web (63) qui lui meme les transmet (etape 903) au module 
5 d'authentification (73). Le module d*authentification (73) interroge (etape 904) la base 
de donnees locale ou distante (via une interface ODBC par exemple) en operant une 
recherche sur le numero ENUM E.164. Celle-ci foumit a Tetape 905 les informations 
d'authentification correspondantes au module d'authentification (73) qui se charge de 
les comparer avec le pseudonyme et mot de passe saisis par le client ENUM. En cas 

10 de concordance, le module d'authentification (73) notifie h Tetape 906 le module 
serveur web (63) que Fauthentification est reussie. Celui-ci emet a Tetape 907 a 
destination du module script ENUM (75) une requete de lecture du profil ENUM. Le 
script ENUM (75) emet une demande d'interrogation a Tetape 908 au module de 
gestion de protocole DNS (62) en foumissant en argument Fadresse E-164 de Tabonne 

15 ENUM transformee sous forme de domaine (transformation du numero de telephone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion 
de protocole DNS (62) qui joue le role d'un RESOLVER interroge (etape 909), si les 
informations ne sont pas deja dans son cache suite a une consultation precedente, a 
I'aide du protocole standard DNS (requete DNS Query), le serveur DNS de niveau 0, 

20 le serveur DNS de niveau 1, puis le serveur DNS de niveau 2 via son module de 
protocole DNS (32). De preference, pour gagner en efficacite, les donnees d'un DNS 
sont chargees dans la memoire vive du serveur (31), Si Tabonne ENUM est 
eflFectivement enregistre dans le serveur DNS (31) du foumisseur de service ENUM 
(30), le module de gestion de protocole DNS (32) retoume a Tetape 910 le/les 

25 enregistrement(s) NAPTR correspondant(s) . Le module de gestion de protocole DNS 
(62) se charge de les retransmettre vers le module script ENUM (75) a Tetape 91 1. Ce 
dernier analyse et interprete le/les enregistrement(s) NAPTR, par exemple: 

SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 
30 INNAPTRlOOlO "u" 

. "ldap+E2U"'M^+33296053859$!ldap://ldap.fournisseurA.fi-/cn=33296053859!" 



Le script ENUM detecte qu'il s'agit d'un service LDAP. Par consequent, le 
module script ENUM ^75) emet a Tetape 912 a destination du module de gestion 
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protocole LDAP (64) une requete LDAP de denude de connexaon vers le serveu^ 
LDAP reference par VUKl "ldap://ldap.foumisseurA.fr". Ce dernier 6met a 1 etape 913 
une requete "Bind" a destination du module protocole LDAP (35) du serveur annuaire 
LDAP (34) du fournisseur ENUM A (30). Le module protocole LDAP(35) accepte la 
5 connexion , I'.tape 914. Le module de gestion de protocole LDAP (^) ^-J ^^-; 
I'etape 915 a destination du module protocole LDAP (35) la requete LDAP Search 
en foumissant le numdro E.164 de I'abomt^ ENUM en argument. Le module protoco e 
LDAP (35) interroge la base de domiees LDAP (36) a I'etape 916 puis retoume a 
r^tape 917) I'ensemble des informations concemant Vabonne ENUM au module 
10 protocole LDAP (35) qui lui-meme les retoume (etape 918) au module de gestion de 
protocole LDAP (64). Ce dernier retoume les informations a I'etape 919 au scrxpt 
ENUM (75) qui se charge de les mettre sous une forme comprehensible pour labonne 
ENUM avant de les transmettre (a I'etape 922) vers le serveur web (63). Le serveur 
t^echarge ensuite la page web generic dynamiquement ^ I'etape 923 sur le temun^ 
15 web (8) de Fabonne ENUM. En paraUele, le module de gestion de protocole LDAP 
(64) envoie a I'etape 920 une demande de decomiexion au serveur LDAP (34) vm une 
requae "Unbind". Le module de protocole LDAP (35) confirme la d6comie«on a 
I'etape 9:^1. 

20 La Fig 13 decrit la procedure de modification manuelle de profil ENUM 

lorsque ce dernier est stocke dans un amxuaire LDAP. Ut encore, une modification de 
profil ENUM par un terminal autre qu'un PC pent bien entendu 6tre envisagee 

L'abonne ENUM ayant precedemment consulte le contenu de son profil ENUM 
au moyen de la procedure d6crite ci-dessus, peut decider de le modifier. Pour ce feare, 
25 il modifie localement dans la page web afifichee sur son terminal web (8) les attnbuts 
de ses services ENUM, les priorites, ajoute des services ou en supprime. 11 vahde ses 
modifications de profil a I'etape 1000 et les informations sont foumies au serveur web 
(63) Ce dernier transmet Vensemble de ces informations a I'etape 1001 au module 
script ENUM (75). Ce dernier emet une demande d'interrogation a I'etape 1002 au 
30 module protocole DNS (62) en foumissant en argument I'adresse E.164 de l'abonne 
ENUM transfom.ee sous forme de domaine (transformation du num^ro de telephone 
E 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion 
de protocole DNS (62) qui joue le role d'un RESOLVER peut interroger, s, les 
informations ne sont pas dej^ dans son cache suite a une consultation precedente (a 
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Tetape 1003) avec le protocole standard DNS (requete DNS Query) le DNS niveau 0, 
puis le DNS niveau 1 , avant d'interroger le DNS niveau 2 via son module de protocole 
DNS (32). Pour gagner en eflScacite, les donnees d'un DNS sont chargees dans la 
memoire vive du serveur DNS (31). Si Tabonne ENUM est effectivement enregistre 
5 dans le DNS (31) du foumisseur de service ENUM (30) le module protocole DNS 
(32) retoume a Tetape 1004 le/les enregistrements NAPTR correspondant(s). Le 
module de gestion de protocole DNS (62) les retransmet alors vers le module script 
ENUM (75) a Tetape 1005. Ce dernier analyse et interprete le/les enregistrement(s) 
NAPTR, par exemple : 

10 

SORIGIN 9.5.8,3.5.0.6.9.2.3.3,el64.arpa. 
IN NAPTR 100 10 "u" 

'Udap+E2U"•M^+33296053859$!ldap://ldap.foumisseurA.fr/cn=33296053859!" 

15 Le module script ENUM (75) detecte qu'il s'agit d'un service LDAP. Le 

module script ENUM (75) emet alors (etape 1006) a destination du module protocole 
LDAP (64) une requete LDAP de demande de connexion au serveur LDAP reference 
par rURI "ldap://ldap.foumisseurA.fr". Ce dernier emet a Tetape 1007 une requete 
"Bind" a destination du module protocole LDAP (35) du serveur annuaire LDAP (34) 

20 du foumisseur ENUM A (30). Le module protocole LDAP(35) accepte la connejfion ^ 
Petape 1008. Le module protocole LDAP(64) emet alors a Petape 1009 a destination 
du module protocole LDAP (35) une requete LDAP "Search" en foumissant le 
num^ro E.164 de Tabonne ENUM en argument. Le module protocole LDAP (35) 
interroge la base de donnees LDAP (36) a Petape 1010 puis retoume a 1' etape 1011 

25 Tensemble des informations concemant Tabonne ENUM au module de gestion de 
protocole LDAP (35). Ce dernier les retoume a Petape 1012 vers le module de gestion 
de protocole LDAP (64) qui lui-meme les retoume (etape 1013) au module de script 
. ENUM (75). Celui-ci les compare avec les informations foumies via le web par 
Tabonne ENUM et determine Poperation a eflFectuer au format LDAP et transmet une 

30 demande de modification a Petape 1014 a destination du module de gestion de 
protocole LDAP (64). Ce dernier envoie une requete LDAP "Modify" ^ P6tape 1015a 
destination du module protocole LDAP (35) qui lui-meme emet h Petape 1016 une 
demande d'ecriture dans la base de donnees (36). Celle-ci accepte la mise a jour et la 
confirme (etape 1017) au module protocole LDAP (35). Ce dernier transmet (6tape 
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1018) la confirmation/infirmation de mise a jour au module de gestion de protocole 
LDAP (64) qui la retoume (etape 1019) au module script ENUM (75). Celui-ci genere 
alors la page web de confirmation de modification avant de la transmettre au serveur 
web (63). Le serveur telecharge cette page (^ape 1023) au terminal web (8) de 
5 I'abonne ENUM. En paraUdle, le module protocole LDAP (64) envoie (etape 1020) 
une demande de d^connexion au serveur LDAP (34) via une requete "Unbind", Le 
module de protocole LDAP (35) confiraie k deconnexion k I'^tape 1 021 . , . . 

Bien que la procedure de mise a jour d'annuaire LDAP ait ete illustree pour une 
10 procedure « manuelle », il va de soi qu'une mise k jour automatique de I'annuaire 
LDAP au moyen de I'automate de configuration (74) peut 6galement ^re envisagee. 

Bien que Tinvention ait ete essentiellement decrite dans le cadre de I'application 
« ENUM » et de la mise a jour d'un profil ENUM , il est clair pour I'homme du metier 
15 qu'elle peut s'etendre a la mise a jour d'un ou plusieurs enregistrement(s) de 
ressource(s) (RR) dans un serveur DNS (ou LDAP), tels que definis au paragraphe 
3.2.2 du document RFC 1035 precite et repris dans la table ci-apr6s : 



Type de RR 


Valeur 


Signification 


A 


1 


Addresse IP d'une machine 


NS 


2 


Nom de serveur gere par une autorit^ administrative 


MD 


3 


Serveur Mail de destination 


MF 


4 


Serveur Mail de reroutage 


CNAME 


5 


Nom canonique pour un alias 


SOA 


6 


Marque le debut d'une zone d'autorite 


MB 


7 


Nom de domaine d'une boite eMail 


MG 


8 


Membre de groupe de mail 


MR 


9 


Nom de domaine de renommage d'un mail 


NULL 


10 


Resource record NULL 


WKS 


11 


Description de service bien connu 


PTR 


12 


Pointeur sur un nom de domaine 
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HINFO 


13 


Information siu* une machine infoimatique 


MINFO 


14 


Information sur une boite mail 


MX 


15 


Echange de mail 


TXT 


16 


Chaines de caracteres 



Pour un enregistrement de ressource donne, la mise a jour pourra porter sur un 
ou plusieurs champs de cet enregistrement, tels que definis dans le document RFC 
1035precite. 

II faut noter que si la raise a jour d*enregistrement(s) de ressources autre(s) que 
NAPTR est envisagee, de nouveaux modules similaires au module « Script ENUM » 
(75) et « automate de configuration ENUM » (74) doivent etre ajoutes pour traiter 
chacun de ces enregistrements. . >^ 
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REVENDICATIONS 



1) Systeme de consultation et/ou de mise a jour d'un enregistrement stocke dans 
une premiere base de donnees (33, 36), ledit enregistrement comprenant un ou une 
pluraUte d'enregistrements de ressources (RR), ladite premiere base de donnees etant 
hebergee par un serveur de noms de domaine, dit serveur DNS, ou un serveur 
d'annuaire, dit serveur LDAP. pouvant €tre accede par indirection a partir d'un 
serveur DNS, caracterise en ce qu'il comprend : 

- des moyens de communication (1150, 53-59, 61,63) permettant audit systeme 
de recevoir d'un terminal de telecommunication une demande de consultation et/ou de 
modification dudit enregistrement ou une programmation d'une teUe demande ; 

- des moyens de controle (1175, 74, 75) adaptes a determiner a partir de ladite 
demande de consultation et/ou de modification transmise au dit systeme ou 
pr^alablement programmee dans ledit systeme, un nom de domaine et une operation a 
eflfectuer sur ledit enregistrement ; 

- des moyens de gestion de protocole (1 162, 62, 64) adaptes a rechercher a partir 
dudit nom de domaine, I'adresse IP dudit serveur hebergeant ladite premiere base de 
donnees et, en fonction de ladite operation, a transmettre au dit serveur une requete de 
lecture ou de mise d jour dudit enregistrement. 

2) Systeme selon la revendication 1, caractdrise en ce qu'il comprend des 
moyens d'authentification (1173, 73) adaptes a authentifier au niveau applicatif 
l'6metteur de ladite demande h partir d' informations d'authentification stockees dans 
une seconde base de donnees (1170,70) locale ou distante. 

3) Systeme selon la revendication 2, caracterise en ce que, I'emetteur de ladite 
demande ayant ete authentifie, lesdits moyens de gestion de protocole sont adaptes a 
transmettre une requete en consultation selon le protocole DNS (DNS Query) audit 
serveur DNS, la requete ayant pour argument ledit nom de domaine, et a recevoir une 
pi«mi6re reponse dudit serveur. 

4) Systeme selon la revendication 3, caracterise en ce que la premiere base de 
donnees etant hebergee par ledit serveur DNS, les moyens de controle sont adaptes a 
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extraire de ladite premiere reponse ime information contenue dans ledit enregistrement 
et a la formater pour la transmettre au dit terminal via lesdits moyens de 
commimication. 

5 5) Systeme selon la revendication 3, caracterise en ce que, la premiere base de 

donnees etant hebergee par ledit serveur LDAP, les moyens de controle sont adaptes a 
extraire de ladite premiere reponse Tadresse du serveur LDAP. 

6) Systeme selon la revendication 5, caracterise en ce que, lesdits moyens de 
10 gestion de protocole sont adapt6s a transmettre une requete en consultation selon le 

protocole LDAP (LDAP Search) audit serveur LDAP et a recevoir de celui-ci une 
seconde reponse. 

7) Systeme selon la revendication 6, caracterise en ce que les moyeni de 
15 , controle sont adaptes a extraire de ladite seconde reponse une information contenue 

dans ledit enregistrement et a la formater pour la transmettre au dit terminal via lesdits 
moyens de communication. 

8) Systeme selon la revendication 4, caracterise en ce que, les moyen§ de 
20 controle ayant determine une operation de mise a jour, les moyens de gestiorj de 

protocole sont adapt6s, sur instruction desdits moyens de contrdle, k transmettre une 
, • requete en mise a jour selon le protocole DNS (DNS Update). 

9) Systeme selon la revendication 8, caracterise en ce que les moyens de gestion 
25 de protocole sont adaptes a recevoir vme reponse de confirmation/infirmation de mise 

a jour du serveur DNS et les moyens de controle sont adaptes a formater cette reponse 
de confirmation/infirmation avant d'en ordonner la transmission au dit terminal via 
lesdits moyens de communication . ^ . 

30 10) Systeme selon la revendication 7, les moyens de controle ayant determine 

une operation de mise a jour, les moyens de gestion de protocole sont adaptes, sur 
instruction desdits moyens de controle, a transmettre une requSte en mise a jour selon 
le protocole LDAP (LDAP Modify). . 
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11) Systeme selon la revendication 10, caracterise en ce que les moyens de 
gestion de protocole sont adaptes a recevoir une reponse de confirmation/infinnation 
de mise a jour du serveur LDAP et les moyens de controle sont adaptes a formater 
cette reponse de confirmation/infinnation avant d'en ordonner la transmission au dit 

5 terminal via lesdits moyens de communication . 

12) Systeme selon k revendication 2, caracterise en ce que les moyens de 
controle sont adaptes a stocker dans la seconde base de donnees un profil de 
configuration transmis via lesdits moyens de communication, ledit profil etant 

10 constitue d'une ou plusieurs demandes de modification programmee, chaque demande 
de modification programmee etant associee a au moins une plage temporelle et/ou une 
zone geographique. 

13) Systeme selon la revendication 12, caracterise en ce que lesdits moyens de 
15 controle comprennent un automate de configuration (74) adapte a scruter Jadite 

seconde base de donnees et a tester si une mesure de temps appartient a ladite plage 
et/ou une localisation du temiinal appartient a ladite zone, et en cas de resultat positif, 
a extrairei la demande de modification programmee associee et a transmettre aux dits 
moyens de gestion de protocole une demande de consultation de la premiere base de 
20 donnees. 

14) Systeme selon la revendication 13, caracterise en ce que lesdits moyens de 
gestion de protocole sont adaptes a formuler ladite requete en consultation selon le 
protocole DNS (DNS Query) ou LDAP (LDAP Search) et a recevoir, du serveur 

25 hebergeant la base de doimees, le contenu dudit enregistrement. 

15) Systeme selon ia revendication 14, caracterise en ce que si le contenu dudit 
enregistrement n'est pas conforme a ladite demande de modification programmee, 
lesdits moyens de controle determinent une operation a elfectuer sur ledit 

30 enregistrement pour le rendre conforme a ladite demande de modification 
programmee et lesdits moyens de gestion de protocole formulent, en fonction de ladite 
operation, une requete de mise a jour de ladite premiere base de donnees selon le 
protocole DNS ou LDAP et Facheminent vers le serveur hebergeant ladite premiere 
base de donnees. 
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16) Systeme selon la revendication 15, caracterise en ce que lesdits moyens de 
gestion de protocole sont adapt6s h recevoir une reponse de confinmtion/infirmation 
de mise k jour du serveur hebergeant la premiere base de donnees et que les moyens 

5 de controle sont adapt^s a detecter ladite reponse de confirmation/infirmation et a la 
stocker sous forme d'historique dans la seconde base de donnees. 

17) Systeme selon la revendication 16, caracterise en ce que lesdits moyens de 
controle sont adaptes a recevoir xme demande de lecture dudit historique, et apres 

10 authentification de Temetteur de ladite demande par lesdits moyens d'authentification, 
a lui transmettre le contenu dudit historique via lesdits moyens de communication. 

18) Systeme selon la revendication 17, caracterise en ce que lesdits moyens de 
gestion de protocole sont adaptes a recevoir une reponse de confirmation/infinrjation 

15 de mise a jour du serveur hebergeant la premiere base de donnees et que les mpyens 
de controle sont adaptes a detecter ladite. reponse de confirmation/infirmation.. et a 
transmettre un cornpte-rendu de ladite operation k un terminal de notification. ^ 

19) Systeme selon Pune des revendications precedentes, caracterise en cp que 
20 lesdits moyens de gestion de protocole sont adaptes a utiliser un protocole Dt^S de 

type securise (DNSSec). 

. 20) Systeme selon Time des revendications pr^cedentes, caracterise en ce qu'il 
comprend une interface RTC et/ou RNIS (51) connectant lesdits moyens de 
25 communication au reseau RTC/ RNIS, 

- * 21) Systeme selon la revendication 20, caracterise en ce que lesdits moyens de 

communication comprennent un module de synthese vocale (55) ou un module de 
reproduction de fichiers vocaux (56) permettant de generer un menu vocal, de 

30 " reproduire une ou des informations dudit enregistrement sous forme vocale, ainsi 
qu'un module de reconnaissance de signaux DTMF (54) et/ou un module de 
reconnaissance vocale permettant de reconnaitre un choix dans ledit menu vocal 
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22) Systeme selon la revendication 20, caracterise en ce que lesdits moyens de 
commimication comprennent un serveur videotex (57) permettant de g^nerer un menu, 
de saisir une demande de consultation ou de modification dudit enregistrement et de 
reproduire une ou des infomiations dudit enregistrement ou une reponse de 

5 confirmation/infirmation de mise a jour sous forme de sequences videotex. 

23) Systeme selon la revendication 20, caracterise en ce que lesdits moyens de 
communication comprennent un module d'emission/reception de messages SMS (58) 
pemiettant de recevoir sous forme de message xme demande en consultation ou de 

10 modification dudit enregistrement et de transmettre sous forme de message une ou des 
informations dudit enregistrement ou une reponse de confirmation/infirmation de mise 
a jour. 

24) Systeme selon la revendication 20 comportant une interface RNIS (51), 
15 caracterise en ce que les moyens de communication comprennent un module 

d'emission/ reception (53) d'information usager a usager lUU, permettant de recevoir 
sous forme d'une dite information TUU, une demande en consultation ou de 
modification dudit enregistrement et de transmettre sous forme d'lme dite information 
lUU une ou des informations dudit enregistrement ou une reponse de 
20 confirmation/infirmation de mise k jour. 

25) Systeme selon la revendication 20, caracterise en ce qu'il comprend un 
module fax (59) permettant de transmettre une ou des informations dudit 
enregistrement ou une reponse de confirmation/infirmation de mise a jour. 

25 

26) Systeme selon Time des revendications 1 a 19, caracterise en ce qu'il 
comprend ime interface IP (60). 

27) Systeme selon la revendication 26, caracterise en ce que les moyens de 
30 communication comprennent un serveur Web adapte a transmettre un formulaire 

d'authentification, un formulaire de saisie d'une demande de consultation ou de 
modification dudit enregistrement, de presenter une ou des informations dudit 
enregistrement ou une reponse de confirmation/infirmation de mise a jour sous forme 
de pages Web. 
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28) Syst^me selon la revendication 26, caracterise en ce que les moyens de 
communication comprennent un serveur SMTP adapte a recevoir sous forme d'emails 
une demande de consultation ou de modification dudit enregistrement et de 

5 transmettre sous foraxe d'emails une ou des infomiations dudit enregistrement ou une 
reponse de confirmation/infirmation de mise a jour. 

29) Systeme selon Tune des revendications precedentes, caracterise en ce que 
les moyens de controle sont adaptes a determiner ledit nom de domaine a partir d'un 

10 identifiant d'abonne. 

30) Systeme selon la revendication 29, caracterise en ce que ledit identifiant 
d'abonne est le numero telephonique E.164 dudit abonne. 

■ 

15 31) Systeme selon la revendication 29 ou 30,. caracterise en c^e que lesdits 

moyens de controle sont adaptes ^ extraire des informations et a determiner en 
fonction de ladite demande une operation a eflfectuer sur un enregistreraeirt de 
ressource de t)T3e NAPTR. 

20 32) Systeme selon Tune des revendications precedentes caracterise en ce-.que 

lesdits moyens de contr61e sont adaptes a extraire des informations et k determiner en 
fonction de ladite demande une operation a effectuer sur un ou plusieurs 
enregistrements de ressource de type A, NS, MD, MF, CNAME, SO A, MB, MG, MR, 
NULL, WKS, PTR, HINFO, MINFO,MX, TXT. 
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